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REMARKS 

Claims 1-23 are pending in this application, stand rejected, and are at issue herein. 
Reconsideration of the grounds of rejection of claims 1-23 and indication of their allowability at 
an early date in view of the following remarks are respectfully solicited. 

The Examiner has rejected claims 1-6 under 35 U.S.C. §102(e) as being anticipated by 
Bakshi, U.S. Patent No. 6,457,054. The Applicant has thoroughly considered the Examiner's 
application of the reference, but must respectfully traverse this ground of rejection. 
Reconsideration of this ground of rejection and indication of the allowability of claims 1-6 at an 
early date are respectfully solicited. 

Independent claim 1 requires, inter alia, "establishing a first communication channel 
between the first processor and the second processor through the proxy server. . . ; and 
establishing a second communication channel between the first processor and the second 
processor through the proxy server. . . " As is clear from this independent claim 1 , two separate 
communication channels must be established between the first processor and the second 
processor through the proxy server. As such, any system that does not establish two separate 
communication channels as specified by this independent claim 1 cannot anticipate this claim, or 
those claims dependent thereon. 

The Bakshi '054 reference, however, does not establish two separate communication 
channels at all. Instead, Bakshi '054 describes a system in which the user-visible latency for 
communication between two network devices is reduced. This is done by minimizing the three 
way handshake typically required for HPPT communications. However, only a single 
communication channel is opened in the system of Bakshi '054. This single channel is clearly 
illustrated in FIG., 4 of Bakshi '054. A second communication channel is not illustrated in FIG., 
4 nor is there any description of the same. 

Indeed, the abstract of the Bakshi '054 patent describes, in the singular, "the second 
network device transmits a response packet to the first network device that includes a 
confirmation of the request to establish a new connection and a reply to the request for data. A 
connection between the first and second network devices is maintained after receipt of the 
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response packet." (emphasis added). Further, the summary of the invention section also 
describes, in the singular, the establishment of a single communication channel between the 
client and server at line 19-22 v^hich reads "the request packet includes a request to establish a 
connection in a request for data, wherein the request to establish a connection includes a 
connection identifier." (emphasis added). This summary concludes, also with a description in 
the singular, that " a connection is then maintained between the first and second network devices 
after receipt of the response packet." Bakshi '054, column 2, lines 28-30 (emphasis added). 

In rejecting this independent claim 1 , the Examiner cites to a prior art FIG. 1 , and to 
column 2, line 51 -column 3, line 30 of Bakshi '054 to meet the limitations of both the first 
communication channel and the second communication channel. However, FIG. 1 clearly 
illustrates only the opening of a single client/server TCP exchange for an HTTP transaction. No 
second communication panel is illustrated between the client and server whatsoever. 
Furthermore, the cited text beginning at column 2, line 5 1 merely describes the typical HTTP 
transaction using TCP and a three-way handshake performed to establish a single connection. 
Specifically, lines 56-57 states "a three-way handshake is performed to establish a connection 
(that is, open a socket) between an HTTP client device and server device." (emphasis added). 
However, Bakshi describes that this typical procedure magnifies the user-visible latency. 

This cited text continues in column 3, line 15 to describe an approach to reduce the user- 
visible latency due to this TCP handshaking. However, this approach known as persistent HTTP 
or P-HTTP also only opens a single connection. As stated in column 3, line 19-22 "this approach 
seeks to limit user-visible latency by performing the TCP handshake procedure only once, at the 
beginning of a data exchange, and then maintain a persistent connection for the duration of the 
exchange." (emphasis added). As with the previous discussion, this text also identifies only a 
single connection between the client and server. Bakshi '054 does not describe that the typical 
HTTP connection and the persistent HTTP connection are both opened, but describes that these 
are two different techniques, each opening only a single connection. 

The Applicant has further studied the remainder of the un-cited description of Bakshi 
'054 and were unable to find any discussion of a method of bi-directionally communicating that 
requires the establishment of a first communication channel and a second communication 
channel as claimed in claim 1 . Instead, the system of Bakshi '054 provides a system for reducing 
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user- visible latency for communicating between two network devices over a single connection 
between the two devices. Therefore, the Applicant respectfully submits that Bakshi '054 cannot 
anticipate independent claim 1 because it wholly lacks any teaching or suggestion of the 
establishment of two communication channels between the first processor and the second 
processor through the proxy server. Reconsideration of this ground of rejection and indication of 
the allowability of claim 1 and those claims dependent thereon, to wit claims 2-12, at an early 
date are respectfully solicited. 

In addition to the reasons stated above, claim 2 requires the step of "transmitting a first 
HTTP-based 'request' to the second processor via the proxy server, the first 'request' including at 
least one of the first messages therein." To meet his limitation, the Examiner points to the 
request packet described in the abstract, and to column 1, line 51 to column 2, line 30. However, 
it is clear from a reading of the abstract that the request packet is simply a request to establish a 
new connection, and does not include at least one of the first messages to be transmitted on the 
first communication channel. Instead, this request packet may be selectively accepted or denied 
by the second network device to establish a new connection therebetween. 

As described in the abstract "the second network device selectively accepts the new 
connection or discards the request based on a comparison of the connection identifier to a 
corresponding connection identifier that it maintains." Indeed, the abstract goes on to describe 
that '*a connection between the first and second network devices is maintained after receipt of the 
response packet " that the second network device sends to the first network device, (emphasis 
added). It is not until the connection has been established that the two network devices can 
exchange any messages. This is specifically set forth in the summary of the invention section in 
column 2, line 18 wherein it is stated "the request packet includes a request to establish a 
connection and a request for data, wherein the request to establish a connection includes a 
connection identifier." Nowhere in this description does it say that the request includes any of 
the messages to be exchanged between the client and server. Instead, the request packet of 
Bakshi '054 merely is a request to establish a connection and a request for data from the server. 
Once the server accepts the connection, the server then transmits its message to the client over 
that connection. Therefore, the Applicant respectfully submits that Bakshi '054 cannot anticipate 
claim 2 for this additional reason. 
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In addition to the reasons stated above with regard to claim 1 , claim 3 requires the step of 
"transmitting a second HTTP -based 'request' to the second processor via the proxy server to be 
parked a the second processor, the second 'request' establishing a persistent HTTP connection 
between the first processor and the second processor through the proxy server." As claimed, 
only a single request is transmitted from the client to the server via the proxy server to be parked 
at the second processor. In the system of claim 3, this parked request establishes a persistent 
HTTP connection between the first processor and the second processor through the proxy server. 

In the system of Bakshi '054, the establishment of persistent HTTP connection actually 
requires "performing the TCP handshake procedure only once, at the beginning of the data 
exchange, and then maintaining a persistent connection for the duration of the exchange." 
Bakshi '054, column 3, lines 19-22. As is clearly set forth in this cited section, Bakshi '054 
requires that the entire TCP handshake be performed before the beginning of the data exchange 
and before the persistent connection between the client and server will be maintained. In other 
words, the "request" from the client is not parked at the server, but instead triggers a three-way 
TCP handshake procedure that must be completed before the data exchange may begin and 
before the persistent connection may be maintained. As such, Bakshi '054 does not anticipate 
this claim 3 for this additional reason. Reconsideration of this ground of rejection and indication 
of the allowability of claim 3 and those claims dependent thereon, to wit claims 4-11, for this 
additional reason are respectfully solicited. 

In addition to the above, claim 4 requires the step of "receiving an HTTP-based "reply" 
from the second processor on the second communication channel, the HTTP-based "reply" 
including at least one of the second messages therein." As just discussed, the persistent HTTP 
connection described in column 3 cited by the Examiner requires that the entire TCP handshake 
procedure be performed, albeit only once, at the beginning of the data exchange before the 
persistent connection can be maintained. As such, there is no description that the HTTP-based 
"reply" includes any messages to be exchanged from the server to the client. Instead, messages 
are only exchanged once the TCP handshake procedure has been performed. Therefore, the 
Applicant respectfully submits that Bakshi '054 cannot anticipate claim 4. Reconsideration of 
claim 4 for this additional reason and indication of its allowability, and the allowability of claim 
5 dependent thereon, for this additional reason are respectfully solicited. 
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In addition to the above, claim 5 requires the step of "transmitting a third HTTP-based 
"request" to the second processor via the proxy server in response to receiving the HTTP-based 
"reply", the third HTTP-based "request" containing an acknowledgement for the HTTP-based 
"reply" and further establishing a persistent HTTP connection between the first processor and the 
processor through the proxy server." However, the transmission of such a third HTTP-based 
request to establish a persistent HTTP connection is contrary to the teachings of Bakshi '054 
which describes that the TCP handshake procedure is performed only once, at the beginning of 
the data exchange, to maintain the persistent connection "for the duration of the exchange." 
Therefore, the Applicant respectfully submits that Bakshi '054 cannot anticipate claim 5 for this 
additional reason. Reconsideration of claim 5 and indication of its allowability at an early date 
are therefore respectfully solicited. 

In addition to the above, claim 6 requires that "the first processor only receives an HTTP- 
based "reply" from the second processor on the second communication channel, when the second 
processor has at least one of the second messages to send to the first processor." Unlike the 
requirements of claim 6, the cited sections of Bakshi '054 all describe the transfer of client- 
requested information. Specifically, Bakshi '054 describes in column 4, line 59-21 "the reply to 
the request from the client device may include all of the data requested or only a portion of that 
data, as is known in the art." Similarly, column 5, line 11-14 describes "the client device reuses 
the same connection to request all the URLs contained in the HTML document returned by the 
server device... " In response to these requests, the server immediately sends the requested data. 

Claim 6, however, requires that the first processor only receive the HTTP-based "reply" 
from the second processor when the second processor has at least one of the second messages to 
send to the first processor. If the processor does not have a second message to send, no HTTP- 
based reply is received. This is contrary to the teachings of Bakshi '054. Therefore, the 
Applicant respectfully submits that Bakshi '054 cannot anticipate claim 6 for this additional 
reason. Reconsideration of claim 6 and indication of its allowability at an early date are 
therefore respectfully solicited. 

The Examiner has rejected claims 7-23 under 35 U.S.C. § 103(a) as being unpatentable 
over Bakshi '054 in view of Boyle et al., U.S. Patent No. 6, 11 9, 167. The Applicant has 
thoroughly considered the Examiner's rationale for combining these references, and the teachings 
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of these references as so combined, but must respectfully traverse this ground of rejection. 
Reconsideration of this ground of rejection and indication of the allowability of claims 7-23 in 
view of the following remarks at an early date are respectfully solicited. 

It is axiomatic in the patent law that there must be some suggestion or motivation for 
modifying or combining the teachings of the prior art, that there must be some reasonable 
expectation of success from the teachings so combined, and that the combination must teach 
each and every limitation of the claims. Additionally, it is important to note that a conclusory 
statement regarding the suggestion or motivation to combine the references is not sufficient to 
support a prima facie case. See In re Lee, 61 USPQ2d 1430, 1433. 

In this case, the Examiner has stated that Bakshi '054 and Boyle '167 are in the same field 
of endeavor and in an analogous art, in that the combination of these references would have been 
obvious "for the purpose of optimizing for the cost and latency parameters." The Applicant 
respectfully submits that this is a mere conclusory statement that does not have any bearing on 
providing a suggestion or motivation to one of ordinary skill in the art to combine the teaching of 
these two references. As such, the applicant respectfully submits that this statement cannot 
support the proposed combination. 

With regard to the optimization for cost, the system of Bakshi '054 does not appear to 
have any cost component that needs to be optimized since it merely describes a different 
connection technique for reducing user-visible latency for communications between two network 
devices. The cost of completing a three-way TCP handshake versus the cost of implementing the 
single message of Bakshi '054 to establish a persistent connection would not appear to be a 
component that one of ordinary skill in the art would believe needs to be optimized. That is, the 
Applicant respectfully submits that there is no appreciable cost associated with the transmission 
of three network messages to establish an HTTP connection versus the transmission of a single 
message including a connection identifier of Bakshi '054. Therefore, the Applicant respectfully 
submits that an optimization for cost cannot support this proposed modification. 

Further, the system of Bakshi '054 is already directed to a system for reducing the user- 
visible latency in a network transaction by reducing the number of packets that must be 
transmitted to form the HTTP connection. The system of Boyle et al. '167, however, describes 
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that data is stored on an intermediate computer system for a predetermined length of time until it 
is able to provide that data to another device such as a wireless handheld device or cell phone. 
User latency on the scale of Bakshi '054 is not of concern in Boyle et al. '167 because the period 
between synchronization with the portable handheld device may be extensive while the user is 
out of range or otherwise unconnected to the intermediate computer system. Indeed, Boyle et al. 
'167 is not even concerned with the reliable transmission of such messages as the data may be 
simply deleted and never forwarded to the destination if that data is stored for more than a 
predetermined length of time. Therefore, it cannot be said that the system of Boyle et al. '167 is 
concerned with user-visible latency that would result from requiring a three-way TCP 
handshake. This is because Boyle et al. '167 recognizes that it may have to store messages for 
some predetermined length of time while a hand held device is not connected before it is able to 
transmit the data to that device. As such, the Applicant respectfully submits that optimizing for 
latency also cannot support the combination of these references. 

In view of the above, the Applicant respectfully submits that the examiner has failed to 
establish a prima facie case of obviousness as there is no suggestion or motivation for one of 
ordinary skill in the art that can support such a combination. That is, the system of Boyle et al. 
'167 will not optimize the cost parameters of Bakshi '054, nor will the system of Bakshi '054 
optimize the latency seen in the system of Boyle et al. '167. Reconsideration of this ground of 
rejection and indication of the allowability of claims 7-23 at an early date are therefore 
respectfully solicited. 

In addition to the foregoing, the applicant also respectfully submits that there is no 
likelihood of success from a combination of these references. That is, the system of Bakshi '054 
is directed to reducing user- visible latency between two network devices. However, the system 
of Boyle et al. '167 is directed to a data transfer system that transfers data from a web server, 
through an intermediate computer system, to a portable hand-held device. As descried in Boyle 
et al. '167, the transmission of data from the intermediate computer system to the portable 
device, e.g. a cell phone, may use a connectionless protocol. Specifically, the system of Bakshi 
'054 modifies the TCP process for an HTTP data transfer, whereas the Boyle et al. '167 reference 
utilizes the cellular digital packet data (CDPD) standard, the GSM standard, the UGP 
connectionless protocol, or the HDTP (hand held device transport protocol), which is not a mark- 



14 



In re Appln. Of: Shy Cohen 
Application No.: 09/676,924 

up language like HTML. Therefore, the Applicant respectfully submits that a prima facie case of 
obviousness has not been properly established for this reason as well. 

Most telling, however, is the lack of these two references when combined to satisfy each 
and every limitation of the claims of the present invention. As this requirement must be met for 
each individual claim, the following discussion will address this specific point and the failure of 
these references when combined to teach each and every limitation of these claims. 

Claim 7 requires that "the second HTTP-based "request" includes therein a request that 
the second processor transmit a reply after the expiration of a time period even if there is no 
second messages so that the first processor can assess a status of the connection thereto." To 
meet this limitation the Examiner points to Boyle et al. '167, column 10, line 34-colunm 11, line 
33, and column 11, line 34-colunm 12, line 15. However, these sections merely describe that the 
messenger may assign a time to live parameter (MTTL) for each notification received by the 
messenger. If such a message has been held in the messenger queue longer than the MTTL and 
the messenger has not been able to send the notification to the respective browser, the messenger 
deletes the notification from the messenger cue. This time period is completely foreign to the 
time period of claim 7 which requires that the second processor transmit a replay after the 
expiration of the time period even if there are no messages to transmit. The system of Boyle '167 
teaches exactly the opposite. 

In Boyle, if no message has been transmitted after the MTTL, the message is simply 
deleted and will not thereafter be sent. This is required in Boyle et al. '167 because the portable 
hand held device may not be connected to the network. As such, no messages could be 
transmitted thereto. To prevent messages that cannot be sent to an unconnected device from 
filling up memory, these messages are deleted after a period of time. This system is completely 
foreign to the requirements of claim 7. Therefore, the Applicant respectfully submits that claim 
7 is not rendered obvious by the combination of these references. Reconsideration of claim 7 
and those claims dependent thereon, to wit claims 8-11, are respectfully solicited. 

Claim 8 requires "setting the time period to be less than two days." The section cited by 
the Examiner to meet this limitation contains no such description. Indeed, the applicant was 
unable to find any particular time period for the MTTL, although as stated above with regard to 
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claim 7, the MTTL does not meet the limitation of the time period of claim 7. However, the last 
sentence of Appendix 1 states "if time-to-live has not been specified, the time-to-live 28 (FIG. 2) 
is set to a default value (3 days in some embodiments)." In view of this specified teaching of a 
three day default period, the Applicant respectfully submits that the requirement of claim 8 that 
the time period be less than two days is not taught or suggested by this combination of 
references. Therefore, the Applicant respectfully submits that claim 8 is not rendered obvious by 
this combination for this additional reason. Reconsideration of claim 8 and indication of its 
allowability at an early date are respectfully solicited. 

Claim 9 requires "setting the time period to be approximately 5 minutes." As discussed 
above, the only discussion in Boyle '167 of a time period is a default value of three days. As 
such, the Applicant respectfully submits that the setting of a time period to five minutes is not 
taught or suggested by this combination of references. Therefore reconsideration of this ground 
of rejection and indication of the allowability of claim 9 for this additional reason are 
respectfully solicited. 

Claim 10 requires "dynamically adjusting the time period based on a connection time out 
closure controlled by the proxy server." The Applicant respectfully submits that Boyle et al. '167 
is completely devoid of any such description or suggestion. That is, neither the sections cited by 
the Examiner nor the remainder of the disclosure of Boyle et al. '167 teaches or suggests 
dynamically adjusting the time period based upon a cormection time out closure controlled by the 
proxy sever. Therefore, the Applicant respectfully submits that claim 10 is not rendered obvious 
by this combination of references. Reconsideration of this ground of rejection and indication of 
the allowability of claim 10 at an early date are therefore respectfully solicited. 

Additionally, claim 1 1 requires that the dynamic adjusting of a time period comprises 
"receiving a connection time out closure message from the proxy server; determine a first time 
between transmitting the second HTTP-based request and receiving a connection time out 
closure message from the proxy server; and calculating a new time period to be less than the first 
time and less than the time period." The applicant has thoroughly studied the section cited by the 
Examiner, and respectfully submits that the cited sections do not each the receipt of a time out 
closure message, a determination of a further time between transmission and receipt, nor the 
calculation of a new time period that is less than the first time and less than the time period. 
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Therefore, the Applicant respectfully submits that claim 1 1 cannot be rendered obvious in view 
of this combination of references for this additional reason. Reconsideration of this ground of 
rejection and indication of the allowability of claim 1 1 at an early date are respectfully solicited. 

Independent claim 1 2 claims "a computer-readable medium having computer-readable 
instructions for performing the method of claim 1." In rejecting this claim under 35 U.S.C. 
§103 (a) over Bakshi *054 in view of Doyle et al. *167 the Examiner has merely stated that this 
claim is "rejected under the same rationale as claim number 1. However, claim 1 was not 
rejected under 35 U.S. C. § 103(a) in view of this combination of references. Therefore, the 
Applicant is unclear as to the ground of rejection being set forth by the Examiner since paragraph 
13 of this Office Action includes claim 12 and the rejection based on 35 U.S.C. §103(a). 
Therefore, should the Examiner decide to maintain this ground of rejection, the Applicant 
respectfully requests clarification thereof. However, the Applicant respectfully traverses this 
ground of rejection for the reasons stated above with regard to claim 1. 

Independent claim 1 3 requires "transmitting and HTTP-based request to the server via the 
proxy server to open a persistent connection therewith, HPPT-based request requesting a reply 
from the server only when the server has messages to send the client." To meet this limitation 
the examiner cites to column 11, line 65-column 12, line 10 of Boyle et al. '167. However, in 
this cited section, several alternatives are provided for how the user may request mail service. 
None of the recited alternatives teach or suggest that an HTTP -based "request" requests a reply 
from the server only when the server has messages to send to the client. While this cited section 
does end with the statement "this is not an exhaustive list of how the user may control the push 
operation to optimize the cost and latency parameters" such an open-ended, nebulous statement 
is not sufficient to provide a teaching of the special requirements of independent claim 13. That 
is, a reference that leaves to the imagination all possibilities cannot provide a teaching or 
suggestion of the specific requirements of this claim. 

Further, the delivering of mail does not address the preliminary establishment of the 
HTTP connection itself That is, in the system as claimed in independent claim 13, the server is 
not to send an HTTP -based reply in response to the HTTP-based request as is the typical 
scenario in forming an HTTP connection. Instead, the server is directed not to send an HTTP- 
based reply in response to the HTTP -based request until and unless the server actually has a 
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message to send to the client. In the system of Boyle et al. '167, however, a full persistent 
connection has already been established before the cited section discussing mail delivery can 
take place. In other words, it appears that the system of Bole et al. *167 has completed the three- 
way handshake to establish a persistent HTTP connection before the mail forwarding rules are 
implemented. As such, the Applicant respectfully submits that independent claim 13 cannot be 
rendered obvious in view of this combination of references. Reconsideration of this ground of 
rejection and indication of the allowability of independent claim 13 and those claims dependent 
thereon, to wit claims 14-19, are respectfully solicited. 

The Examiner has rejected claim 14 under the same rationale as claim 7. Therefore, the 
Applicant respectfully traverses this ground of rejection for the additional reasons set forth above 
with regard to claim 7. 

The Examiner has rejected claim 15 under the same rationale as claim 10. Therefore, the 
Applicant respectfully traverses this ground of rejection for the additional reasons set forth above 
with regard to claim 10. 

The Examiner has rejected claim 16 under the same rationale as claim 1 1 . Therefore, the 
Applicant respectfully traverses this ground of rejection for the additional reasons set forth above 
with regard to claim 1 1 . 

The Examiner has rejected claim 17 under the same rationale as claim 11,3, and 7. 
Therefore, the Applicant respectfully traverses this ground of rejection for the additional reasons 
set forth above with regard to claim 11,3, and 7. 

The Examiner has rejected claim 18 under the same rationale as claim 1 1 and 5. 
Therefore, the Applicant respectfully traverses this ground of rejection for the additional reasons 
set forth above with regard to claim 1 1 and 5. 

The Examiner has rejected claim 19 under the same rationale as claim 13. Therefore, the 
Applicant respectfully traverses this ground of rejection for the additional reasons set forth above 
with regard to claim 13. 
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Independent claim 20 requires the steps of "receiving and HTTP-based request 
originating from the client through the proxy server; and parking the HTTP-based request 
without responding thereto unless the message is generated that needs to be transmitted to the 
client; and when the message is generated generating an HTTP-based reply to the HTTP-based 
request parked for the client, the HTTP-based reply containing the message therein; and 
transmitting the HTTP-based reply." However, neither of these references taken alone or in 
combination teaches the step of parking the HTTP-based request without responding thereto 
unless a message is generated that needs to be transmitted to the client. Specifically, each of the 
references cited by the Examiner will fully complete the establishment of a persistent HTTP 
connection between the client and server. Neither of the references describes the parking of an 
HTTP-based request. 

The Examiner has pointed to the alert or notification messages of Boyle et al. '167. 
However, it is clear that both the alert and notification messages are generated after the HTTP 
connection has been established. The Examiner has pointed to no specific section of either of 
these references, and the Applicant was unable to find any description of the parking of an 
HTTP-based request without responding until a message is generated that needs to be transmitted 
to the client. 

Further, the Applicant was unable to find, and the Examiner pointed to no section that 
specifically described that the HTTP-based reply to the HTTP-based request parked for the client 
contains the message to be transmitted thereto. In view of the above, the applicant respectfully 
submits that claim 20 is not rendered obvious by this combination of references. 
Reconsideration of this ground of rejection and indication of the allowability of claim 20 and 
those claims dependent thereon to wit claims 21-23, at an early date are respectfully solicited. 

Claim 21 also requires the step of "receiving a second HTTP-based request containing a 
message acknowledgement from the cHent through the proxy server; parking the second HTTP- 
based request." To meet this limitation, the Examiner points to Boyle et al. '167, FIG. 32, arrow 
HOLD ON. However, the Boyle et al.'167 patent describes in Appendix Al, Section 1.1.5 that 
the arrow indicated as HOLD ON is actually a "request acknowledgement... sent by the UP 
Gateway to the client to inform it that the request has arrived successfully and any further 
retransmission is urmecessary." Boyle et al. '167, column 24, lines 23-29. 
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In other words, receipt of an HTTP-based request will not be parked, but instead will 
generate the transmission of a HOLD ON acknowledgement. However, as described in the 
specification of the instant application, page 17, beginning at line 16 and continuing through 
page 18, line 12, the server parks the HTTP request instead of sending any acknowledgement or 
reply to keep the second communication channel open so the server may then send a message to 
the client when such becomes available. As should be apparent, this parking functionality is 
completely foreign to the system of Boyle et al. 167 which, instead, generates an 
acknowledgement message referred to therein as the arrow HOLD ON. Therefore, the Applicant 
respectfully submits that claim 21 cannot be rendered obvious by this combination of references 
for this additional reason. Reconsideration of this ground of rejection and indication of the 
allowability of claim 21 at an early date are respectfully solicited. 

Claim 22 requires that the step of parking the HTTP-based request comprises "parking 
the HTTP-based request without responding thereto until the expiration of the connection of the 
time out period; and when the connection time out period expires generating an HTTP-based 
reply to the HTTP-based request parked for the client and transmitting the HTTP -based reply. 
As discussed above, Boyle et al. '167 is wholly devoid of any parking functionality that results in 
the server withholding a response. Further, Boyle fails to teach that the expiration of the time 
out period results in the generation of an HTTP-based reply to the parked request. Instead, at the 
expiration of the time period discussed in Boyle et al. '167, messages held in the queue that have 
not been delivered are simply deleted. The Examiner did not specifically identify and the 
Applicant was unable to find any discussion in Boyle et al. '167 that described the generation of 
a HTTP-based reply and its transmission after a time out period had expired. As such, the 
Applicant respectfully submits that claim 22 is not rendered obvious over this combination of 
references for this additional reason. Therefore, reconsideration of this ground of rejection and 
indication of the allowability of claim 22 at an early date are respectfully solicited. 

The Examiner has rejected claim 23 under the same rationale as claim 20. Therefore, the 
Applicant respectfiilly traverses this ground of rejection for the same reason stated above withy 
regard to claim 20. 
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In view of the above, the Applicant respectfully submits that claims 1-23 are in condition 
for allowance. Reconsideration of claims 1-23 in view of the foregoing remarks and indication 
of their allowability at an early date are respectfully solicited. 

If the Examiner believes that a telephonic conversation will aid in the resolution of any 
issues not resolved herein, the Examiner is invited to contact the Applicant's attorney at the 
telephone number listed below. 




leg. No. 37390 
IT & MAYER, LTD. 
ix Road, Suite 300 
Illinois 61114-8018 
(815) 963-7661 (telephone) 
(815) 963-7664 (facsimile) 



Date: October 12, 2004 
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